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The  ability  to  emplace  stand-alone  payloads  in  hostile  territory  has  long  been  on 
the  wish  list  of  US  warfighters.  This  type  of  activity  is  often  conducted  at  great 
danger.  We  have  developed  a  capability  for  automated  payload  placement  from 
unmanned  ground  vehicles  (UGVs)  using  the  Automatic  Payload  Deployment 
System  (APDS)  that  can  greatly  reduce  this  danger.  For  example,  payloads 
equipped  with  a  radio  repeater  and  a  camera  can  be  deployed  to  support  the 
securing  of  tunnels,  caves,  and  other  previously  cleared  areas.  Example 
battlefield  applications  may  include  delivering  food,  ammunition,  and  medical 
supplies  to  the  warfighter.  Covert  operations  may  require  the  unmanned 
emplacement  of  a  network  of  sensors  for  human-presence  detection,  or  infrared 
illuminators  at  high-interest  locations.  The  APDS  architecture  is  extremely 
modular,  allowing  third-party  developers  to  produce  these  capabilities,  and 
more,  for  a  wide  variety  of  unmanned  vehicles.  APDS  design  and 
demonstrations  will  be  discussed  in  this  paper. 

INTRODUCTION 

The  use  of  robotics  in  the  battlefield  continues  to  grow.  Unmanned  aerial  vehicles  (UAVs) 
have  been  used  to  carry  out  surveillance  missions  and  occasionally  engage  in  air-to-ground 
attacks.  Unmanned  ground  vehicles  (UGVs)  have  been  primarily  used  in  neutralizing  improvised 
explosive  devices  (IEDs),  but  they  have  also  been  used  as  look-ahead  and  surveillance  tools.  The 
role  of  UGVs  will  become  more  diverse  as  research  in  areas  such  as  mapping1,  exploration, 
human-robot-interaction2,  and  collaborative  behaviors  such  as  the  UAV  refueling  system3, 
eventually  transition  to  the  battlefield  environment. 

Payload  delivery  and  placement  is  another  area  that  will  contribute  to  the  ever  increasing  role 
of  robotics.  The  Space  and  Naval  Warfare  (SPAWAR)  Systems  Center  (SSC)  Pacific  has 
developed  this  capability  under  the  Automatic  Payload  Deployment  System4  (APDS)  project.  A 
UGV  carrying  the  APDS  can  deliver  a  mixed  variety  of  payloads  to  desired  locations.  For 
example,  a  UGV  can  run  provisions  into  hostile  environments  to  replenish  food,  ammunition,  and 
medical  supplies,  thereby  eliminating  the  need  of  placing  warfighters  in  harm’s  way.  In  covert 
operations  a  UGV  can  deliver  a  network  of  surveillance  sensors  to  a  desired  location,  which  may 
lie  beyond  the  radio  line-of-sight  (LOS)  needed  to  control  the  UGV.  In  this  case,  additionally 
carrying  radio  repeaters  that  automatically  deploy  can  extend  the  range  of  the  UGV  en  route  to 
the  location  where  the  sensors  are  to  be  emplaced. 
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Now  in  its  second  iteration,  APDS  has  been  redesigned  to  be  extremely  modular.  The 
modular  architecture  allows  APDS  to  easily  interface  with  a  wide  variety  of  UGV  platforms  and 
eases  the  development  efforts  necessary  for  payloads  designed  by  third-parties.  The  Background 
section  briefly  summarizes  the  previous  systems  that  have  led  to  the  current  APDS.  The  Modular 
APDS  section  defines  the  hardware  and  software  architectures  of  the  current  system.  The  System 
Verification  section  will  discuss  testing  and  demonstrations. 

BACKGROUND 

The  predecessor  of  APDS  was  the  Automatically  Deployed  Communication  Relays5  (ADCR) 
system,  developed  to  provide  non-line-of-sight  (NLOS)  operational  capability  to  any  UGV 
capable  of  communicating  over  Internet  Protocol  (IP)  and  interfacing  to  the  system  via  an 
Ethernet  connection.  The  ADCR  system  essentially  replaces  the  native  radios  of  the  UGV  and  its 
associated  controller  (in  most  instances  they  are  merely  deactivated  through  software  and  not 
physically  replaced).  The  ADCR  Deploy er  can  carry  up  to  six  radio  repeaters  called  Relay 
Bricks,  which  are  automatically  deployed  when  and  where  needed  to  maintain  the 
communications  link  with  the  control  station  of  the  UGV.  Once  deployed  the  Relay  Bricks  self¬ 
right  and  extend  the  antenna  to  maintain  connectivity  with  the  control  station.  This  system  has 
been  demonstrated  onboard  an  iRobot  PackBot  EOD  (See  Figure  1)  with  great  success,  which  led 
to  the  licensing  of  the  technology  to  three  commercial  companies. 


Figure  1.  ADCR  system  onboard  iRobot  PackBot  EOD  showing  Deployer  with  five  stowed  Relay 
Bricks  and  one  deployed  with  extended  antenna. 

During  ADCR  system  demonstrations,  military  users  pointed  out  several  other  useful  payloads 
that  could  be  deployed  by  the  system.  Therefore,  development  of  APDS  began  specifically  to 
add  the  capability  of  deploying  a  mixed  variety  of  payloads  along  with  the  ability  to  deploy  Relay 
Bricks.  Therefore,  a  new  APDS  architecture  was  developed  to  address  this  capability.  This  led 
to  the  requirement  for  the  Deployer  and  its  stowed  payloads  to  communicate  bi-directionally, 
which  was  not  possible  with  the  ADCR  system.  The  messages  exchanged  between  the  Deployer 
and  its  payloads  can  be  as  simple  as  reporting  the  size  and  type  of  the  payload  in  each  bay  of  the 
Deployer  or  as  complex  as  network  parameters  necessary  for  successful  boot  up  of  Relay  Bricks. 

A  new  APDS  Deployer  was  designed  based  on  the  new  architecture.  To  satisfy  the  bi¬ 
directional  communications  requirement,  each  bay  in  the  Deployer  contains  an  Infrared  Data 
Association  (IrDA)  transceiver,  which  is  used  to  communicate  with  the  associated  payload  in 
half-duplex  mode.  Because  APDS  was  also  designed  to  improve  upon  the  network  performance 


of  the  ADCR  system,  the  onboard  radio  of  the  APDS  Deployer  was  upgraded.  This  upgrade 
significantly  improved  the  network  reliability  and  roundtrip  latency.  The  payload  ejection 
mechanism  was  simplified  for  improved  reliability.  The  width  was  reduced  to  half  that  of  the 
ADCR  Deployer,  which  allowed  it  to  occupy  only  one  of  the  three  bays  onboard  the  PackBot 
EOD  (see  Figure  2). 

A  new  Next  Generation  (NG)  Relay  Brick  was  also  developed  as  part  of  the  improvement 
upon  the  ADCR  Relay  Brick.  The  NG  Relay  Brick  was  designed  to  work  with  the  APDS 
Deployer  so  it  also  supports  an  IrDA  interface  and  an  upgraded  radio.  The  design  of  the  antenna 
lift  mechanism  was  simplified  to  increase  reliability.  The  active  antenna  lift  mechanism  ensures 
that  the  antennas  will  be  vertical  regardless  of  the  slope  and  surface  material  on  which  the  NG 
Relay  Brick  lands  after  deployment. 


Figure  2.  The  APDS  Deployer  onboard  iRobot  PackBot  EOD  with  three  stowed  NG  Relay  Bricks 

and  one  deployed  with  extended  antenna. 

In  addition  to  the  NG  Relay  Brick,  two  other  payloads  were  developed  to  demonstrate  the 
ability  of  the  APDS  Deployer  in  handling  a  mixed  variety  of  payloads.  The  illuminator  node 
(Figure  3)  is  a  payload  that  supports  an  array  of  near-infrared  FEDs,  mounted  between  the 
antenna  masts,  providing  approximately  uniform  illumination  of  the  surrounding  area.  The  FEDs 
can  be  activated  remotely  allowing  covert  night-time  observation  of  critical  areas  or  high-value 
targets.  The  camera  node  (Figure  3)  is  a  double-wide  payload  (i.e.  twice  the  width  of  an  NG 
Relay  Brick)  and  supports  a  camera  with  a  fleld-of-view  of  greater  than  180°  vertical  and  360° 
horizontal.  The  camera  is  mounted  between  the  antenna  masts  and  is  oriented  pointing  up 
allowing  observation  of  the  horizon  via  the  streaming  video. 

The  control  station  of  the  PackBot  EOD  requires  the  same  radio  hardware  found  in  the  APDS 
Deployer  and  NG  Relay  Bricks  in  order  for  APDS  to  properly  form  a  mesh  network  between  the 
UGV  and  its  controller.  The  Base  Station  Unit  (BSU)  was  developed  for  this  purpose  as  well  as 
to  provide  status  information  reported  by  the  APDS  Deployer  and  the  various  payloads.  Manual 
deploy  commands  can  also  be  sent  from  the  BSU  to  eject  payloads  at  strategic  locations. 


Figure  3.  The  illuminator  node  (left)  and  camera  node  (right). 


MODULAR  APDS 

Part  of  the  motivation  for  developing  APDS  was  to  improve  upon  the  NLOS  operational 
capability  offered  by  the  ADCR  system.  Similar  to  the  ADCR  system,  APDS  replaces  the  native 
wireless  communications  system  of  the  UGV  and  its  controller  (see  Figure  4). 
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Figure  4.  Illustration  of  the  APDS  wireless  replacement  system.  Data  is  relayed  between  the  UGV 
and  the  BSU  via  the  deployed  NG  Relay  Bricks. 


In  order  to  form  the  mesh  network  necessary  in  providing  NLOS  operational  capability  for  the 
UGV,  the  APDS  Deployer  must  carry  onboard  the  same  radio  found  in  the  NG  Relay  Brick  and 
the  BSU.  An  Ethernet  interface  is  also  required  to  connect  the  UGV  controller  to  the  BSU  and 
the  UGV  to  the  APDS  Deployer.  These  necessities  and  the  requirement  to  support  various 
payloads  pose  three  issues. 


Issue  1 :  Not  all  UGVs  that  could  benefit  from  APDS  communicate  over  IP. 


For  example,  the  Foster  Miller  Talon,  a  widely  used  UGV  for  counter-IED  missions  in  theater, 
uses  an  analog  radio  to  transmit  video  to  its  controller  and  a  secondary,  non-IP  based  radio  to  link 
Command  and  Control  (C2)  data,  preventing  the  Talon  from  interfacing  with  the  APDS 
Deployer.  This  is  not  an  issue  for  the  PackBot,  which  communicates  over  IP  and  provides  an 
external  Ethernet  interface. 


Issue  2:  The  APDS  communications  system  may  not  be  suitable  for  the  mission  at  hand. 

In  some  cases,  the  APDS  operating  frequency  may  be  inappropriate  or  the  network 
performance  may  be  inadequate.  In  fact,  the  native  communications  system  of  the  UGV  may  be 
more  appropriate.  For  these  cases,  APDS  can  still  be  used  for  other  non-networking  tasks,  such 
as  emplacing  surveillance  sensors  in  a  specific  location,  running  provisions  into  hostile 
environments,  or  delivering  a  payload  like  the  illuminator  node  to  a  desired  area.  These  types  of 
tasks,  however,  have  no  need  for  the  onboard  APDS  Deployer  radio  and  so  its  occupied  real 
estate  and  cost  can  be  eliminated. 


Issue  3:  Every  payload,  no  matter  how  simple,  must  communicate  over  IrDA. 

Because  the  APDS  architecture  requires  each  payload  to  communicate  with  the  APDS 
Deployer,  every  payload  must  include  the  necessary  IrDA  electronics  and  support  the  mechanical 
interface  needed  for  latching  and  ensuring  alignment  of  the  IrDA  windows  in  stow  mode.  These 
requirements  complicate  the  electronic  and  mechanical  design  of  the  payloads. 


To  solve  the  issues  described  above,  a  modular  approach  to  the  APDS  design  is  taken.  Under 
the  Modular  APDS  (APDS-M)  architecture  the  Deployer  and  the  payloads  are  each  divided  into 
two  separate  sections,  as  shown  in  Figure  5.  The  Deployer  is  now  composed  of  the  Deployer 
Module  (DM)  and  the  Deployer  Module  Adapter  (DMA),  which  communicate  over  the  Deployer 
Module  Interface  (DM-I).  Similarly,  the  payload  is  composed  of  the  Payload  Carrier  (PC)  and 
the  Payload  Carrier  Adapter  (PCA),  which  communicate  over  the  Payload  Carrier  Interface  (PC- 
I).  The  PCA  and  the  DM  communicate  over  the  IrDA  interface  when  the  payload  is  stowed 
within  the  DM. 
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Figure  5.  Separate  sections  of  the  payload  and  Deployer  under  the  Modular  APDS  architecture. 


The  purpose  for  separating  the  APDS  Deployer  into  two  parts  is  to  place  all  essential  functions 
of  the  Deployer  into  the  DM  and  all  other  functions  (including  functions  specific  to  the  UGV 
hosting  the  system)  into  the  DMA.  The  DM  functions  include  releasing  payloads,  managing 
communications  with  the  payloads  over  IrDA,  and  displaying  battery  capacity  and  other  status 
information  for  the  user  on  the  LCD  screen.  Therefore,  the  DM  hardware  consists  of  the 


individual  bays  where  the  payloads  are  stowed,  the  release  motors,  IrDA  transceivers,  battery 
pack,  fuel  gauge,  LCD,  and  the  microcontroller  that  manages  all  the  functions  and  communicates 
with  the  DMA. 

The  purpose  for  separating  the  payload  into  two  parts  is  to  place  all  functions  related  to 
communicating  and  interfacing  mechanically  to  the  Deployer  into  the  PCA  and  the  main  function 
of  the  payload  into  the  PC.  Quite  literally,  the  PCA  is  an  adapter  that  allows  any  type  and  size  of 
payload  to  interface  with  the  DM. 

This  separation  of  functions  is  best  illustrated  by  referring  to  Figure  6,  which  is  an  equivalent 
representation  of  the  APDS  architecture  (see  Figure  4)  under  the  APDS-M  architecture.  The 
APDS  Deployer  radio  notifies  the  microcontroller  when  a  Relay  Brick  is  to  be  released.  This  is 
determined  automatically  based  on  signal  strength  information  or  by  receiving  a  manual  deploy 
command  from  the  BSU.  In  either  case  the  microcontroller  takes  the  necessary  steps  in  releasing 
one  of  the  Relay  Bricks.  Because  the  function  of  the  APDS  Deployer  radio  is  specific  to  the 
wireless  communications  system  and  does  not  contribute  to  the  essential  functions  of  the  DM,  it 
must  be  placed  in  the  DMA  under  the  APDS-M  architecture. 

The  illustration  of  Figure  6  also  shows  that  a  PCA  is  attached  to  each  PC  regardless  of  the  type 
and  size,  to  provide  a  common  means  of  interfacing  to  the  DM. 
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Figure  6.  Equivalent  representation  of  the  NLOS  operational  capability  offered  under  the 

Modular  APDS  architecture. 


The  APDS-M  architecture  addresses  issues  1,  2  and  3  discussed  earlier.  It  is  easy  to  see  that 
the  DMA  can  allow  a  greater  variety  of  UGVs  to  benefit  from  APDS-M.  For  example,  a  Talon- 
DMA  can  be  developed  that  converts  the  non-IP  based  C2  and  video  data  into  IP  traffic  that  can 
be  relayed  via  Relay  Brick  payloads  providing  NLOS  operational  capability  for  the  Talon.  The 
traffic  would  have  to  be  converted  back  into  the  original  non-IP  C2  and  video  data  on  the 
controller  side,  which  would  require  additional  hardware.  However,  ongoing  development  of 
common  software  controllers,  such  as  the  Multi-robot  Operator  Control  Unit6  (MOCU)  will 
render  the  original  controller  of  the  UGV  obsolete  and  there  will  not  be  any  need  for  additional 
converter  hardware.  Only  a  radio  identical  to  the  radios  inside  the  Talon-DMA  and  Relay  Brick 
payloads  will  be  required  to  interface  to  a  MOCU-based  controller.  Finally,  the  modular  payload 
approach  will  ease  development  of  payloads  since  third-party  developers  will  not  have  to  be 
concerned  with  the  required  IrDA  electronics,  IrDA  window,  and  mechanical  interface  to  the 
Deployer. 


Deployer  Module  and  Adapter 

The  DMA  and  DM  prototypes  are  shown  in  Figure  7.  The  DM  is  identical  to  that  shown  in 
Figure  2  but  with  the  radio  removed  and  placed  in  the  DMA.  The  external  face  of  the  DMA 
shows  the  UGV  interface  connector.  The  internal  face  shows  the  DM-I  connector.  For  this 
prototype  the  DM-I  interface  contains  RS232,  power-in,  and  power-out  pins.  The  DMA  radio 
communicates  with  the  DM  microcontroller  via  the  RS232  connection.  Since  the  DM  is 
internally  powered  and  the  DMA  is  not,  the  DM  provides  power  to  the  DMA  radio  via  the  power- 
out  pins.  The  power-in  pins  are  used  to  charge  the  internal  battery  pack  of  the  DM. 


Figure  7.  DM  and  PackBot-DMA  prototypes 

The  DMA  can  be  made  to  be  UGV-specific  as  well  as  function-specific.  For  example,  the 
DMA  shown  in  Figure  7  is  PackBot-specific  and  its  function  is  to  provide  NLOS  operational 
capability  with  the  use  of  Relay  Brick  payloads.  If  a  Talon  requires  NLOS  operational  capability 
the  DMA  can  contain  the  required  electronics  to  convert  the  video  and  C2  data  to  IP  traffic.  If 
NLOS  operational  capability  is  not  required  but  there  is  a  need  to  robotically  deliver  other  types 
of  payloads  the  DMA  may  simply  hold  a  bank  of  battery  packs  to  extend  the  operational  period  of 
the  host  UGV  as  well  as  the  DM.  The  objective  is  to  swap  the  DMA  based  on  mission 
requirements  and  the  UGV  utilized. 

Payload  Carrier  and  Adapter 

The  PC  A  and  PC  are  shown  in  Figure  8.  The  internal  face  of  the  PC  A  shows  the  PC-I.  The 
external  face  shows  the  IrDA  window  and  latch  catch.  Two  PC  examples  are  shown  to  illustrate 
that  different  size  payloads  are  supported  by  the  DM.  The  triple-wide  and  the  single-wide 
payloads  are  both  empty  containers  that  can  carry  food,  medical  supplies,  extra  batteries,  or 
whatever  else  is  required  for  delivery.  The  length  of  the  empty  payload  may  be  increased  to 
allow  for  more  space  and  is  limited  only  by  practicality. 


Triple-wide 
Empty  Payload 


Single- wide 
Empty  Payload 


PC-I 


PCA 


IrDA 

Window 


Figure  8.  PCA  and  examples  of  triple-wide  and  single-wide  payload  prototypes. 


The  PCA  electrically  interfaces  with  the  PC  via  the  PC-I  connection  and  mechanically  mounts 
via  two  screws.  This  allows  the  payload  to  interface  with  the  DM.  If  another  payload  type  is 
required  the  PCA  can  simply  be  removed  and  attached  to  the  new  PC.  The  PC-I  contains  power- 
in,  TTL  serial,  and  many  10  pins.  Since  the  PCA  is  not  internally  powered  it  requires  power  from 
the  PC.  The  PCA  has  a  wide  input  voltage  range  of  3V  to  30V,  typical  current  consumption  of 
60mA  at  peak  activity  and  43 pA  in  sleep  mode.  The  PCA  is  typically  in  sleep  mode  when  the 
payload  is  stowed  and  always  in  sleep  mode  after  deployment.  The  sleep  mode  allows  the  PC  to 
last  many  months  without  recharging  if  the  only  current  drain  comes  from  the  PCA.  These 
specifications  help  to  ease  the  design  requirements  of  the  PC. 

The  TTL  serial  and  IO  lines  help  to  support  a  variety  of  payload  types.  For  the  empty  payload 
the  IO  lines  provide  the  size  and  type  information  by  simply  pulling  low  a  specific  set  of  lines. 
Another  payload  type,  like  the  illuminator  node,  may  require  activation  just  prior  to  deployment. 
Again  the  IO  lines  can  be  used  to  not  only  read  the  size  and  type  of  the  payload  but  also  to 
activate  the  IR  LED  array  just  prior  to  payload  ejection.  Finally,  more  sophisticated  payloads  like 
the  Relay  Brick  can  use  the  TTL  serial  lines  to  provide  size  and  type  information  and  receive 
network  parameters,  such  as  service  set  identification  (SSID)  and  operating  channel.  Whatever 
the  payload  size  and  type,  the  internal  electrical  requirements  for  interfacing  with  the  PCA  are 
simply  a  battery  and  the  PC-I  mating  connector. 

Communications  Architecture 

All  of  the  devices  under  the  APDS-M  architecture  communicate  with  one  another  by  using  the 
APDS  Internal  Communications  (AIC)  protocol.  The  DMA  may  translate  the  AIC  protocol  to 
something  the  host  UGV  can  understand,  like  Ethernet.  The  AIC  protocol  is  based  on  the  S- 
expression  structure  and  was  chosen  because  of  reduced  memory  requirements,  faster  parsing, 
and  ease  of  implementation. 

The  APDS-M  architecture  employs  a  master-slave  scheme.  The  master  devices  are  the  DMA, 
UGV,  and  BSU.  The  slave  devices  are  the  DM,  PCA,  and  PC.  The  purpose  of  a  master  device  is 
to  manage  the  payloads  stowed  within  the  DM.  This  requires  learning  the  size  and  type  of  each 
payload,  providing  any  required  information  to  a  payload,  obtaining  status  information  by  polling 
each  payload,  and  commanding  their  release.  Communication  with  a  slave  device  is  always 


initiated  at  the  master  level  and  is  either  generated  onboard  the  DMA  (e.g.  command  the  release 
of  a  Relay  Brick  payload)  or  comes  from  the  UGV  or  BSU  (e.g.  request  remaining  DM  battery 
capacity,  command  manual  deployment  of  supply  payload,  etc.).  Regardless  of  which  master 
device  generates  the  command,  it  is  always  forwarded  to  the  target  slave  device  via  the  DMA. 
When  a  master  device  is  to  communicate  with  the  PC,  the  DM  and  the  PC  A  simply  act  as  relays 
for  the  command  and  the  corresponding  acknowledgement.  The  communications  flow  is  shown 
in  Figure  9. 
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Figure  9.  Communications  flow.  The  Ethernet  interface  is  subject  to  change  as  required  by  the  UGV. 

Shaded  arrows  signify  communications  using  the  AIC  protocol. 

Payload  Delivery  Tasks 

As  discussed  under  Issue  2,  the  native  wireless  communications  system  of  the  UGV  may  be 
more  appropriate  for  a  mission  where  payloads  must  still  be  delivered  to  a  desired  area.  In  this 
case  the  payloads  can  be  deployed  in  one  of  four  ways: 

Method  1 :  Manually  deployed  by  operator. 

This  requires  the  UGV  controller  to  interface  with  the  BSU  and  forward  any  messages  from 
the  BSU  to  the  UGV.  The  UGV  then  forwards  the  manual  deploy  command  to  the  DMA,  which 
is  then  forwarded  to  the  DM  microcontroller  for  deployment  of  the  payload. 

Method  2:  Automatically  deployed  by  UGV. 

The  decision  to  deploy  a  payload  can  come  from  the  UGV.  For  example,  the  UGV  can  be 
programmed  with  GPS  location  data  where  a  set  of  surveillance  payloads  are  to  be  deployed. 
Upon  arrival  at  a  specified  location  the  UGV  forwards  a  deploy  command  to  the  DMA. 

Method  3:  Automatically  deployed  by  DMA. 

The  decision  to  deploy  a  payload  can  come  from  the  DMA.  Suppose  the  mission  is  to  explore 
a  building.  The  UGV  is  sent  to  investigate  each  room  but  if  the  room  is  too  dark  then  it  may  be 
difficult  to  see  what  is  inside.  In  this  case  the  Deployer  can  be  loaded  with  several  illuminator 
nodes  and  the  DMA  equipped  with  a  sort  of  light  sensor.  When  an  area  is  too  dark  the  DMA  can 
command  the  release  of  an  illuminator  node  that  is  activated  just  prior  to  deployment. 

Method  4:  Automatically  deployed  based  on  payload  data 

Suppose  the  mission  is  to  continuously  monitor  a  mine  for  harmful  gasses  by  the  use  of  gas¬ 
sensor  payloads  delivered  by  a  UGV.  The  payloads  can  be  polled  to  determine  if  they  have 
detected  any  gasses.  If  so,  the  DMA  will  issue  a  deploy  command  to  release  the  payload  for 
continued  monitoring  of  the  area. 


SYSTEM  VERIFICATION 


Demonstrations  of  APDS-M  were  conducted  onboard  a  PackBot  EOD.  The  Deployer  was 
loaded  with  a  triple-wide  empty  payload  (shown  in  Figure  8)  and  a  few  NG  Relay  Bricks.  As  of 
this  writing  a  Relay  Brick  payload  utilizing  the  PCA  has  not  yet  been  developed,  so  a  NG  Relay 
Brick  was  substituted.  This  is  a  valid  substitution  since  the  NG  Relay  Brick  communicates  using 
the  AIC  protocol  and  already  employs  all  the  required  IrDA  circuitry. 

With  a  mixed  variety  of  payloads  loaded  into  the  Deployer  the  PackBot  was  teleoperated  away 
from  the  base  station.  The  NG  Relay  Bricks  were  automatically  deployed  to  maintain  the  link. 
At  a  desired  location  a  manual  deploy  command  for  the  triple-wide  empty  payload  was  issued 
from  the  BSU.  This  command  was  received  by  the  Deployer  and  the  empty  payload  ejected. 

This  simple  demonstration  validates  the  communications  flow  of  Figure  9,  the  AIC  protocol, 
the  modular  payload  concept,  and  the  ability  to  handle  mixed  size  and  type  payloads  by  the 
Deployer. 

CONCLUSION 

The  ADCR  system  evolved  into  APDS  to  not  only  enhance  the  wireless  communications 
system  used  in  providing  NLOS  operational  capability  to  the  host  UGV  but  also  to  allow  robotic 
delivery  of  a  mixed  variety  of  payloads.  Because  APDS  is  based  on  the  ADCR  system  the  host 
UGV  must  be  capable  of  communicating  over  IP  to  properly  interface  with  the  APDS  Deployer. 
Furthermore,  the  operating  frequency  and  network  performance  of  the  current  APDS  may  not  be 
suitable  for  some  missions.  For  these  reasons  the  APDS-M  architecture  was  developed,  which  is 
no  longer  constrained  to  a  specific  UGV  interface  and  wireless  system.  This  allows  UGVs  that 
do  not  communicate  over  IP  to  still  attain  NLOS  operational  capability.  Or  the  UGV  can  use  the 
Deployer  to  deliver  a  mixed  variety  of  payloads  to  desired  locations.  Furthermore,  the  modular 
payload  approach  under  the  APDS-M  architecture  eases  the  design  requirements  for  third-party 
payload  developers. 

This  modular  architecture  is  currently  being  used  to  develop  a  wireless  communications 
system  for  NLOS  operational  capability  that  is  suitable  for  operation  in  theater. 
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